home *** CD-ROM | disk | FTP | other *** search
/ Everything For A Hacker / 19990506-[HACK].iso / SECURE / HDD / SECDRV.ZIP / BUGS13A.DOC < prev    next >
Text File  |  1994-03-29  |  8KB  |  203 lines
  1. SecureDrive Version 1.3c replaces version 1.3a.  A prototype version
  2. 1.3b was sent to a few people for testing.
  3.  
  4. Changes for 1.3c have added minimal new function.  Rather I have
  5. sought to respond to problems brought to my attention.
  6.  
  7. Problem:
  8.  
  9. CRYPTDSK messages indicate incorrect compatibility mode.
  10.  
  11. Solution:
  12.  
  13. This was a simple bug. Fixed in 1.3c.
  14.  
  15.  
  16. Problem:
  17.  
  18. CRYPTDSK & LOGIN can't locate some hard disk partitions, especially in
  19. configurations with more than two physical hard disks, from the DOS
  20. drive letter.
  21.  
  22. Solution:
  23.  
  24. This has been a problem since Version 1.0.  Mike added a fix in
  25. version 1.1 which works for most (but apparently not all)
  26. configurations with two physical disks.
  27.  
  28. We don't have a fix, but we do have a workaround.  Both LOGIN and
  29. CRYPTDSK have since version 1.0 allowed you to specify physical drive,
  30. cylinder and head number -instead of- the DOS drive letter. I have
  31. added a simple FPART utility in 1.3b to assist you in finding the
  32. cylinder and head numbers to use.
  33.  
  34. Note that commas (",") must be used to separate these parameters for
  35. CRYPTDSK, while blanks are used for LOGIN.
  36.  
  37. Problem:
  38.  
  39. After I encrypt my hard disk partition or floppy, MSDOS won't
  40. recognize it as a DOS disk, giving me an "Invalid Media" or similar
  41. message.
  42.  
  43. Solution:
  44.  
  45. Apparently, some versions of MSDOS, especially those included with
  46. some laptop PC clones, insist that the SYSTEM ID field of the boot
  47. sector be ASCII characters. Versions of SecureDrive from versions
  48. 1.0 to 1.3a have used the last four characters of SYSTEM ID to store a
  49. 4-byte checkword used to verify that the correct passphrase had been
  50. entered.  This checkword is an MD5 digest of the IDEA key and (in
  51. Version 1.1) the passphrase.  The 128-bit IDEA key is an MD5 digest
  52. (iterated in Version 1.1) of the passphrase.  The checkword is
  53. calculated and stored in the boot sector when the disk partition or
  54. diskette is first encrypted.  Whevever you enter a passphrase to
  55. decrypt or activate the disk, both the key and the checkword are
  56. generated.  The checkword is compared against the one stored in the
  57. boot record as a check that the same passphrase was entered for
  58. decryption as for encryption.  Note that the boot sector is never
  59. itself encrypted.  Also note that since MD5 is a "cryptographicly
  60. strong" one-way digest function, it is not computationally feasible to
  61. find the IDEA key, much less the original passphrase, from the
  62. checkword.
  63.  
  64. Version 1.3c changes the standard location of the checkword to offset
  65. 506 in the boot record. Also the offset of the "CRYP" flag, which
  66. indicates that a disk is encrypted, has been changed from offset
  67. 3 (the start of SYSTEM ID) to offset 502. All eight bytes from
  68. offset 502-509 is called the "CryptFlag."
  69.  
  70. Version 1.3c will place the CryptFlag at offset 502 for all newly
  71. encrypted partitions and diskettes. It will continue to check
  72. for both the "CRYP" flag and the checkword in the SYSTEM ID so
  73. you can still activate or decrypt partitions or diskettes encrypted
  74. by previous versions of SecureDrive.
  75.  
  76. You can convert disks encrypted by previous versions of SecureDrive to
  77. the new standard CryptFlag offset by using the /UCFO [Update CryptFlag
  78. Offset] function with LOGIN (either for hard disk partitions or
  79. diskettes).  Note that /UCFO will overlay SYSTEM ID (the old
  80. CryptFlag) with "MSDOS   ", which means that that disk can no longer
  81. be activated or decrypted with previous versions of SecureDrive.
  82.  
  83. /UCFO doesn't work if combined with the /S (safe mode) parameter.
  84.  
  85. Changing a disk's password with CRYPTDSK will also update the
  86. CryptFlag offset.
  87.  
  88. ATTENTION: Version 1.3b users.
  89.  
  90. Version 1.3b was distributed to a few people for testing. If you
  91. either SET SDOUTCWO=506 or SDOUTCWO=7 (the default), then Version 1.3c
  92. will be able to activate or decrypt your disks encrypted by Version
  93. 1.3b CRYPTDSK  or processed by Version 1.3b LOGIN /UCWO. This is
  94. because Version 1.3c checks for a split CryptFlag.
  95.  
  96. However, Version 1.3c cannot recognize checkword offsets other than
  97. 7 or 506. So if you set SDOUTCWO to something else, you must convert
  98. all such disks to one of the standard offsets BEFORE switching to
  99. Version 1.3c.
  100.  
  101. You can use Version 1.3b to do this. First
  102.  
  103. SET SDINCWO=whatever current non-standard offset is
  104. SET SDOUTCWO=506.
  105.  
  106. Run Version 1.3b
  107.  
  108. LOGIN  xxx /UCWO
  109.  
  110. on all disk partitions and on all diskettes.
  111.  
  112. Problem:
  113.  
  114. I used the recently released 2M/2MF diskette TSR/Format program from
  115. Spain to format a diskette.  I then encrypted it with CRYPTDSK, which
  116. seemed to run normally, but after that LOGIN /F told me the disk was
  117. unencrypted and all the disk data is garbled.
  118.  
  119. Solution:
  120.  
  121. 2M/2MF sets the SYSTEM ID field in the boot record and won't allow any
  122. other program to change it (if 2M.COM is loaded).  Version 1.3c of
  123. SecureDrive also solves this problem by moving the offset for the
  124. CryptFlag out of SYSTEM ID to offset 502.
  125.  
  126. Problem:
  127.  
  128. After I used [some disk utility] LOGIN and CRYPTDSK always say I have
  129. entered an incorrect passphrase for my encrypted disk.  I'm SURE I
  130. used the right passphrase.
  131.  
  132. Another possible problem might be that SecureDrive says the disk
  133. is not encrypted, but it obviously is encrypted since the DOS "DIR"
  134. command displays garbage.
  135.  
  136. Solution:
  137.  
  138. Mike has a report from a user who used some disk utility that re-wrote
  139. his boot record, overlaying the checkword (but apparently not the
  140. "CRYP" flag).  This is probably a different manifestation of the
  141. problem mentioned above.  This disk-fixing utility wants to see an
  142. all-ASCII SYSTEM ID and will set ASCII where it doesn't find it.
  143.  
  144. As a way to fix this, I've added the /RCF [Recover CryptFlag]
  145. parameter to LOGIN.  This will allow you to activate a disk even if
  146. the checkword doesn't match, or the "CRYP" flag has been destroyed.
  147. You will be asked to enter the passphrase twice.  The new checkword
  148. will be written at new standard offset 506 which will hopefully avoid
  149. a repetition of the problem the next time you use that same utility.
  150.  
  151. You are not allowed to recover the CheckWord if SD10CMP=X, since
  152. this setting does now allow LOGIN to compute or check version 1.1
  153. compatible checkwords.
  154.  
  155. Also, if after you enter the checkword, you get garbage when trying
  156. to read the disk, change SD10CMP from Y to N (or vice versa) and try
  157. LOGIN xxx  /RCF again.
  158.  
  159. /RCF also doesn't work if combined with the /S (safe mode) parameter.
  160.  
  161. Note that extreme caution is required when using this parameter. If
  162. you force activation of a disk with the wrong passphrase, it's
  163. effectively the same as accessing the disk without SECTSR loaded.  Any
  164. write to the disk will likely make -all- data on the disk partition or
  165. diskette unreadable.
  166.  
  167. Problem:
  168.  
  169. CRYPTDSK (and FPART) may not work while SECTSR is installed.
  170.  
  171. Solution:
  172.  
  173. If this occurs, try re-ordering device drivers & TSR's which might
  174. effect diskette access.  Note that CRYPTDSK/FPART will reach below
  175. SECTSR to do sector disk I/O, so any TSR's loaded after SECTSR will
  176. also be bypassed by CRYPTDSK/FPART.
  177.  
  178. CRYPTDSK and FPART may be used without SECTSR loaded if necessary.
  179.  
  180. Problem:
  181.  
  182. CRYPTDSK, FPART and/or LOGIN don't work in a DOS Window of Windows.
  183.  
  184. Discussion:
  185.  
  186. I have been able to get LOGIN to activate disks in a Windows DOS
  187. window. However LOGIN /PGP and its variants do not set PGPPASS. SET
  188. doesn't work either.
  189.  
  190. It's probably better to call LOGIN in your AUTOEXEC for Windows, if
  191. possible, and get your disk logged in before loading Windows.
  192.  
  193. I have been able to start CRYPTDSK in the DOS window and it ran fine.
  194. But if I switched to another window, it crashed in the middle. I don't
  195. see how this can be anything but a Windows problem.  Since crashing
  196. CRYPTDSK in the middle essentially destroys all the data on the disk,
  197. I don't recommend trying to run CRYPTDSK under Windows.
  198.  
  199. Of course, SECTSR must be loaded before Windows. DON'T load SECTSR in
  200. a DOS Window.
  201.  
  202.  
  203.